Finding proofs and checking proofs

The classic dichotomy between proof discovery and proof presentation resurfaces in automated deduction. The LCF style of theorem proving offers a promising way to integrate formal deductive proof with higher-level algorithmic or heuristic forms of mathematical activity. One way of dealing with the potential inefficiency of a reduction to a formal deductive system is to exploit the separation of proof finding and proof checking. This can be relevant both to the implementation difficulty of computer proof assistants, and the speed with which they run. Exploiting the separation makes it practical to use many of the usual algorithmic and heuristic approaches to mathematical problem-solving while maintaining the soundness of a formal deductive system. There is an interesting analogy with the NP and co-NP complexity classes. 1 Forms of mathematical activity Classical deductive presentations of mathematics, the style of which goes back to Euclid, often show little trace of how the results and the proofs were arrived at. Sometimes the process of discovery is very different, as shown in the study of Euler’s theorem on polyhedra by Lakatos [19]. For example, Newton is popularly believed to have arrived at most of the theorems of Principia using calculus, but to have translated them into a purely geometric form so that they would be more easily understood, or more readily accepted as rigorous, by his contemporaries. Often the reasons are connected with the aesthetics of the deductive method; for example Gauss compared other considerations besides the deductive proof to the scaffolding used to construct a beautiful building, which should be taken down when the building is finished. This situation is rather strange. Mathematics is distinguished from other sciences by its emphasis on deductive logic rather than inductive, abductive or empirical reasoning. But it seems that creative and problem-solving activities in mathematics are often more successful if they do not need to be shoehorned into a deductive presentation. Such a presentation is regarded as useful principally for two reasons: for the avoidance of error, and for the systematization and collation of mathematical knowledge. Indeed in recent times, formalizability in some system such as ZF set theory has become widely accepted as the ultimate arbiter of correctness for mathematical reasoning. Bourbaki [3] clearly says that ‘the correctness of a mathematical text is verified by comparing it, more or less explicitly, with the rules of a formalized language’, and Mac Lane [20] says almost the same thing (p. 377): As to precision, we have now stated an absolute standard of rigor: A Mathematical proof is rigorous when it is (or could be) written out in the first-order predicate language L(2) as a sequence of inferences from the axioms ZFC, each inference made according to one of the stated rules. [: : : ] When a proof is in doubt, its repair is usually just a partial approximation to the fully formal version. We will not pause to debate this position, which in view of Gödel’s theorems certainly seems to demand some justification. We will simply observe that in practice, mathematicians almost never attempt such complete formalization — in fact, probably relatively few of them could even recite the axioms of ZF set theory. Probably the most sustained formal development of mathematics is the Principia Mathematica of Whitehead and Russell [32], but this book is large and difficult to read, while still only containing relatively elementary mathematics. Possibly mathematicians do have a highly developed intuition about when a mathematical proof could in principle be formalized completely. But in practice mathematicians often think in a quite different way. In particular: Mathematical creativity is often disconnected from any notion of formal deduction, and motivated by physical pictures or amorphous daydreams. In mathematical problem-solving, e.g. differentiating and integrating, there is a tendency to rely on well-known algorithms and heuristics which are assumed sound and useful, without analyzing them on each occasion. Therefore in attempting to analyze mathematical activity, it is interesting to consider the relationship between these different forms of thinking. And if it is desired to provide computer support for them all, we must ask how to mix them together. One possibility is to insist on fully formal deductive proofs at all times, but delegate the production of such proofs to the computer (whose speed and accuracy well equip it for the task), while allowing humans to interact with the computer at a more appealing level. We will consider in detail one fairly successful method of achieving this. 2 LCF-style theorem proving There is a traditional divide in the world of computer theorem proving between ‘automated theorem provers’, which attempt to prove theorems without user assistance, and ‘interactive theorem provers’ or ‘proof checkers’ which merely assist the user in the production of a formal proof, acting as a humble clerical assistant. There are numerous automated provers for first order logic based on tableaux, resolution and model elimination, as well as NQTHM c 1996 J. Harrison ECAI 96. 12th European Conference on Artificial Intelligence Workshop on Representation of Mathematical Knowledge Edited by H. Stoyan, K. Homann, S. Jacob, M. Kerber [4] which proves theorems in quantifier-free first order arithmetic. These have been fairly successful: first order provers have produced new mathematical results in certain fields [1], while NQTHM has been used for an enormous range of tasks including real-life system verification as well as checking theorems from pure mathematics. However in order to tackle real problems, it is necessary to lead automated provers to results via a carefully graded series of lemmas; in general these systems are difficult to control and integrate with specialized algorithms without access to their internals. Moreover, given the complicated and often highly optimized innards of these systems, their correctness can be difficult to guarantee. Notable interactive provers are Automath [7], Stanford LCF [23] and Mizar [31]. These have often proved successful vehicles for the formalization of mathematics, especially Mizar, which has amassed an unrivalled corpus of machine-checkedmathematics. However these systems are relatively labour-intensive to use, since the user must direct the proof at quite a low level. In particular, no facilities are provided for automating special-purpose inference patterns, which often makes proofs tedious. The Edinburgh LCF system [12] was an attempt to combine the best features of both, and moreover, to make it possible for ordinary users to incorporate their own domain-specific extensions without compromising the security of the logic. The original system implemented Scott’s Logic of Computable Functions (hence the name LCF), but as emphasized by Gordon [10], the LCF approach is applicable to any logic. There are now numerous descendants such as Coq and Nuprl which implement constructive type theories, and HOL [11], the system we ourselves are involved with, which implements classical higher order logic. A slightly more radical member of the LCF family is Isabelle [24] which allows multiple object logics embedded in a higher order metalogic. In LCF-like systems, the ML programming language is used to define data types representing logical entities such as types, terms and theorems.A number of ML functions are provided which produce theorems; these implement primitive inference rules of the logic. Thus, provided only the primitive ML inference rules are used, any theorem resulting will be ‘correct’. Such adherence to the primitive rules is enforced by encoding theorems as an ML abstract datatype whose only constructors are the primitive inference rules of the logic. Anything of type thm must have arisen by applying the primitive rules. This trustworthiness is attractive, but proofs of nontrivial facts in terms of primitive inferences are often extremely tedious, and the approach so far offers few, if any, advantages over a simple proof checker. However since a full programming language is available, one can program complicated patterns of inference, provided they ultimately decompose into primitives. Hence one can write derived inference rules which work at a higher level. In order to exploit them, a user may just call the functions, without understanding how they decompose into primitives. Only the original implementor of the derived rule need understand that. Because of the abstract datatype, a user can have equal confidence in the correctness of the resulting theorems, since ultimately they must arise by primitive inference. The user or derived rule is still free to decompose and rebuild terms and formulas in any way desired in order to decide on proof strategy 1 In May 1995, there was a public announcementthat the ‘Robbins conjecture’ had been provedusing the REVEAL theorem prover.This was subsequently traced to a bug in REVEAL, and the conjecture is still open. 2 The name ML is derived from ‘Meta Language’; following Tarski [29] and Carnap [6] it has become usual in formal logic to enforce a strict separation between the object logic and the metalogic (which is used to reason about the object logic). etc. — and the extremely simple term structure of HOL makes this very convenient. Nevertheless all theorems must be built by primitive inference. In this way, the LCF approach can offer the reliability and controllability of a low level proof checker together with the power of a more sophisticated prover. For example, HOL has derived rules for rewriting, associative-commutative rearrangement, linear arithmetic, tautology checking, inductive definitions and free recursive type definitions, among others. Moreover it can support different proof styles such as goal-directed proof, all ultimately decomposing to primitives, and can easily be linked to or incorporated within other systems becauseeverything is accessiblevia ML — yet becauseof the abstract type thm, no false ‘theorems’ can arise. Hence LCF seems an ideal vehicle for the integration of deductive reasoning with specialized algorithmic and heuristic methods, which can be built on top in an elaborate edifice. However, the LCF approach forces all reasoning to decompose to primitives. What grounds do we have for believing that this is practical even for a computer? It’s well-known that computers are amazingly fast, and getting faster, but it’s equally well-known that their speed cannot defeat problems which have an inherent combinatorial explosion. Can algorithms be written in this style, and are the resulting proofs of a size and complexity which is tractable? Perhaps surprisingly, it often is practical — a detailed analysis and a comparison with other techniques such as reflection is given by Harrison [15]. We can identify two clear reasons why the apparent difficulties are often not really serious. First, complex patterns of inference can often be encoded as single theorems, proved once and for all. These can then be instantiated for the case in hand rather cheaply. This idea has long been used by HOL experts; for an early example see [22]. A more recent, and complex, example is the following [13] justifying a step in a quantifierelimination procedure for the reals; it states that a finite set (list) of polynomials are all strictly positive throughout an interval if and only if they are all positive at the middle of the interval and are nonzero everywhere in it. ` 8l; a; b: a < b^ (8x: a < x ^ x < b) FORALL (POS x) l) = a < b^ FORALL (POS (a+b 2 )) l^ :9x: a < x ^ x < b ^ EXISTS (ZERO x) l Many special-purpose algorithms can be understood as a natural process of transformation. It is not difficult to store theorems which justify the individual steps; the algorithm can often be implemented almost as one would do without the primitive inference steps, and generally with a modest linear slowdown (there are a few delicate points over the efficiency of equality testing, but that’s more or less true). This applies, for example, to HOL’s implementation of rewriting and definition of inductively defined relations, as well as numerous special-purpose rules that users write in the course of their work, e.g. the conversion to differentiate algebraic expressions by proof described by Harrison [14]. The second reason harks back to the introduction above: the processes of proof discovery and proof checking can be quite different, not just for the community of human mathematicians, but for a theorem proving system like HOL. It is not necessary for each step of a higher-level algorithm or heuristic to be decomposed lock-step to a series of deductive steps. It’s quite possible to use a completely separate checking phase. Finding proofs and checking proofs 11 J. Harrison 3 Finding versus checking From the perspective of computer theorem proving, there are interesting differences between proof finding and proof checking. For example, it is very straightforward and cheap to multiply together two large prime numbers on a computer, for example: 3490529510847650949147849619903898133417764638493387843990820577